Systems and methods for dynamic monitoring of test taking

ABSTRACT

A system and process for dynamic security monitoring of test taking. The system combines historical information about the test taker or relevant conditions, and includes sensors which objectively monitor test taker&#39;s actions, inactions, and involuntary response to the test given before and during the test, and at a specific test location. The information collected from the sensors is compared to a plurality of predetermined individual risk factors, which indicate a possibility of test fraud by the individual test taker to create a test event risk profile. The individual risk profile is combined with non-individual specific risk factors to create a holistic test event security profile. Security resources are then dynamically assigned to or removed from the test event based on the unique test event security profile.

CROSS REFERENCE TO RELATED APPLICATION

This application claims the priority and benefit of U.S. ProvisionalPatent Application Ser. No. 62/660,563, titled “Systems and Methods forDynamic Monitoring of Test Taking,” filed on Apr. 20, 2018, the entiretyof which is incorporated herein by reference.

FIELD OF THE INVENTION

The present disclosure relates to a system and device to verifyidentity, verify presence, and verify compliance with rules of behaviorin a test session or a remote test session.

BACKGROUND

Today, high-stakes or low-stakes test are delivered, presented oradministered to test takers, whether students, prospective students,workers or prospective workers, usually using computers (laptops,desktops, tablets, smartphones, and others). Some tests, however, arestill administered by paper and pencil. This invention would apply tothose tests as well, but, due to its dynamic nature, the invention isbetter suited for administering computerized exams. This inventionapplies to all tests, however designed, created, administered or used.

The dominant requirement of such testing, particularly high-stakes tests(e.g., MCATs, SATs, college course exams, certification exams,employment and pre-employment tests, personality tests, and others), isto make sure there is enough security in place so that the riskassociated with test fraud—cheating and test theft—is greatly reduced.If such test fraud is allowed, then the test scores cannot be used forthe purposes designed (e.g., certification of skills, academicachievement, academic potential, etc.). Security can take many forms,but the one used ubiquitously is proctoring, or monitoring of testtakers during a test session. The purpose of such monitoring is todetect cheating and/or test theft, or to deter such behavior. However,other security measures are possible. For example, the design of itemsand tests can reduce exposure and increase unpredictability so that testtakers will be less motivated to harvest or steal content, or to usesuch information to cheat. Other security measures are used to detertest takers from such fraud by informing them of security rules andpunishments, and by having them sign non-disclosure agreements, oaths orhonor codes.

A test event is defined as a test taker taking or sitting for a test.One established fact about the current test administration process isthat proctoring or monitoring security procedures are applied to alltest events more or less equally. Test administration rules are usuallyclear as to the number of human monitors to be used based on the numberof test takers in the room. This applies to testing centers and otherlocations (for example, gymnasiums for Saturday SAT testing) and toonline monitoring. No effort is ever made to evaluate the risk of aspecific test event, meaning the risk individual test takers and theircircumstances pose to test security. This is because, before and duringtest administration, no data about the test event (including informationabout the tests, locations, test takers, testing history, new threats,and many more) is gathered or used. Heightened security procedures,designed for the group of test takers, are used almost by default andare universally deployed for all types of test events. Another way tostate this is all test takers are monitored the same way whetherindividual test takers commit or intend to commit, or are even able tocommit different types of test fraud (cheating or test theft). It isclear that such gross and universal security deployment is moreexpensive than it should be and is not the best allocation of resources.

Security is expensive, usually involving the labor of humans, aspreviously mentioned. Proctors are humans tasked with: (1) monitoringtest takers during test administration, and (2) also authenticating eachtest taker to make sure he or she is the person who is supposed to takethe test. For the latter, official ID's are checked, or some otherbiometric may be used. It is accepted that the cost of proctoring is themajor expense of virtually all test administrations. Test administrationcosts (not pricing or fees for a test) per test event typically rangefrom $20 to $50 depending on several factors (e.g., proctor wages,number of simultaneous test events, the cost of location, etc.).Personal cost factors such as the time/cost for test taker travel,parking costs, etc., are not considered in these estimates, they areadd-on costs. Pricing for such tests is then applied providing a margincovering costs for the development of the tests, sales and marketing,profit, and other incidentals. Test administration is considered to beexpensive today, and human-based security efforts are a large part ofthat expense.

If the labor costs of proctors can be reduced, then test administrationbecomes more affordable to all and accessible to those currently unableto afford tests. If the costs can be reduced while at the same timeincreasing the effectiveness of test security, then tests can beadministered in homes, workplaces, and in countries where test securityrisks are currently too high or where test administration costs are tooprohibitive. With such flexibility in testing locations, personal costsof travel time/cost, parking, etc., will be reduced as well.

Currently, test administration models have at least three significantand recognized security flaws.

First, current test administration models, whether physical or online,rely heavily on engaged human proctors. The number of test takers that aproctor may reasonably oversee is limited. As a result, such proctoringmay unnecessarily inflate the cost and pricing of the test event as theproctors are used to oversee a large number of test takers, many or mostof which have no intention of cheating or stealing the test content. Forthat likely majority, the cost of human proctors is completely wasted,and unnecessary for security or other reasons. Furthermore, as theproctors are human, they may be: (1) susceptible to bribery andconflicts of interest, (2) disinclined to monitor closely or well, (3)may shy away from confronting a person when fraud is actually observed,or (4) may have discriminatory biases towards one race, sex, gender,nationality, etc.

Second, test administration is unreasonably tied to set locations, suchas an established testing center, a school classroom, or gymnasium.These testing locations are often themselves a source of securityproblems, as they do not support objective, un-biased monitoring.Indeed, proctors are rarely able to reasonably observe all the testtakers all the time. Additionally, for some disabled test takers,anchoring the test to a single location may add an unreasonable burden(e.g., the location may not be ADA accessible). In addition, test takerswho live in remote locations may not be able to travel to a designatedtesting center. Citizens of some countries cannot afford testadministration fees of current systems let alone travel and parkingexpenses. Indeed, a test administration services vendor, in order tomake a profit, especially in a difficult-to-service country, may have tocharge as much as double or triple the retail price of a test. However,in those countries, often third-world countries, the most that a testtaker may be able to afford would be a small fraction of the test price.Such financial pressures make it difficult to currently provide thehighest quality security offered today in the United States worldwide.

Third, technology used for cheating is becoming harder to detect byhuman observation. For example, the new technology behind hideable,wearable, high-resolution, so-called “spy” cameras, makes it difficult,even impossible for a proctor to prevent or even detect the accuratetheft of any test's entire content. Likewise, wireless ear piecespermitting the test taker to communicate with a third party outside thetesting center continue to shrink to the point that the presence of suchear pieces could only be identified with the assistance ofvisually-enhanced images and invasive searches.

The description of the prior art provided in this disclosure highlightsthe unmet needs for a test monitoring system and method that: (a)evaluates the amount and type of security risk for individual testevents; (b) allows the monitoring to be targeted, competent, remote andobjective; (c) is flexible so as to permit the test event to occur inadditional hard-to-reach and hard-to-service remote locations; (d)includes additional capability to assist in detecting and preventing theuse of technology to cheat or steal test content; and (e) is affordablefor all.

SUMMARY

The invention provides solutions to meet the needs in the industry fortest monitoring systems and methods. Generally, the solutions include,but are not limited to, the following benefits: (i) the ability to takea variety of factors before and during an exam, and use the factors tocalculate initial risk, continuously evaluate risk in real-time, andthen act on that risk in real-time; (ii) the use of cloud-based computersystem(s) to send and receive risk-related information continuously inreal time; (iii) implementation of statistically-based risk analytics,or any formal risk analytics; (iv) the ability to dynamically allocatesecurity resources, depending on a current risk analysis level; (v)validate security of an exam event following conclusion of the test; and(vi) use item and test design features as factors to modify the riskanalysis. These and other solutions are provided by the invention.

Illustrative and alternative embodiments of a computer-based testmonitoring platform are described in detail with reference made to thefigures of this application. The platform is configured to evaluate testsecurity risk and to provide a competent, efficient, and securemonitoring system. The system includes additional detection andprevention tools to assist in monitoring or proctoring, as well as toidentify and prevent cheating and theft. The platform is adaptable sothat a test can be administered through a telecommunications network toa computer in a remote location.

In an exemplary, non-limiting embodiment, the system of the inventioncomprises a computer processor, at least one storage device configuredto store collected data and to recall the stored data, one or moresensors configured to monitor specific risks, a risk analysis andmanagement tool, an applicant file, and a location file. The system isconfigured to permit a test taker to sign into his/her account usingunique identifying credentials, which provide access to the system sothat the system can electronically administer a test that the test takerwill be taking. The system can include at least one authenticationsensor used to verify the identity of the test taker before and duringtest administration. The system is configured for risk analysismanagement to determine the test-taker's security profile for theinitial level of monitoring, which can include proctors and automatedsensors. Then, test administration begins. During the test, one or moresensors used for security detection continuously monitor the test takerand record the occurrence of any threats in the files of the system. Alltesting events are managed by the risk analysis tool that creates thetest taker's unique security profile, evaluates known risks andindicates a security threat (e.g., cheating). The test-taker's securityprofile can change at any time during testing, depending on the specificthreats detected. The test taker's security profile is continuouslycompared to threshold risk profiles stored in the system. Securityresources are then allocated based on the comparison of the test-taker'ssecurity profile to the threshold risk profiles. In one non-limitingembodiment, when the test-taker's security profile risk is higher thanthe threshold risk profile, the test taker may be required to beinstantly monitored one-on-one by a proctor. Conversely, if thetest-taker's security profile is below the threshold risk profile, thetest taker can be monitored by automated monitoring sensors or by humanproctors who may also be monitoring other test takers.

The test-taker's security profile can be constructed from a plurality ofevents that occur during testing. For each characteristic of the testevent captured by one or more sensors of the system, the processor callsup predetermined individual risk factors, previously uploaded by anowner or author of the test or an employee, contractor, or agent of theowner or author, and current security profile, to update thetest-taker's security profile. The adjusted profile may indicate ahigher risk of test fraud by the individual test taker. The processorthen compares the adjusted profile of the individual to the securitythresholds to determine if there is a match within a range of tolerance.This comparison can be noted in the applicant's file and/or the testfile. The processor, at set intervals or continuously, uses the resultof the comparison of the applicant's file to previously uploadedthreshold levels to dynamically allocate changes in security directedtowards the test-taker. For low-risk test taker security profiles, thesystem can indicate continued automatic monitoring by the sensors. Ifthe profile indicates the highest-risk situation, the system cantransmit a notification to a human proctor who can review the event,intervene if necessary and closely monitor the test taker one-on-one.The system can have multiple monitoring levels available, which can beapplied to various levels of test-taker security risk profiles.

The method and non-transitory computer readable medium integrated withinthe system comprises the steps of confirming that a test taker isauthenticated to take a test, creating an initial security risk profilefrom available data for the test taker, and then assigning a securitymonitoring level, ranging from minimal and automated monitoring toone-on-one human monitoring. The method and non-transitory computerreadable medium integrated within the system comprises further the stepsof monitoring actions of the test taker at set intervals or continuouslyto identify relevant test security occurrences during testing. Themethod and non-transitory computer readable medium comprises the step ofcomparing identified security events to a plurality of predeterminedindividual risk factors, which are used to indicate a (1) risk of testfraud, cheating or theft, by the individual test taker, (2) a locationrisk factor based on the test location, and (3) an overall individualrisk level. The method and non-transitory computer readable mediumcomprises the step of comparing the individual security risk profile tothe threshold risk levels to dynamically assign the security measures tobe assigned to the test taker (e.g., computer monitoring, additionalforensics analysis, stopping/pausing the test, in person monitoring,etc.). Finally, if the individual's security profile is above or belowthe current threshold risk level, the method and non-transitory computerreadable medium comprises the step of creating, with a softwareapplication, a log, and then tracking and storing the information thatcomprises and is used to determine changes in the security profile. Aproctor can review the information generated by the method andnon-transitory computer readable medium execute remedial action, asnecessary.

BRIEF DESCRIPTION OF THE FIGURES

Additional aspects, features and advantages of the invention, as to itsmethod and system, structure, components, configuration, functionality,and operability will be understood and become more readily apparent whenthe invention is considered in light of the following description offigures made in conjunction with the accompanying drawings, wherein:

FIG. 1 shows an illustration of the flow of information betweencomponents of the system of the invention.

FIG. 2 shows an illustration of the hardware components of the system ofthe invention.

FIG. 3 shows a flow chart of an embodiment of the functionality of theinvention.

DETAILED DESCRIPTION OF THE INVENTION

The invention provides solutions to the present need in the art forsystems and methods for dynamically monitoring test taking. Theinvention solves the prior art problems using a computer-based testplatform that is specially programmed to monitor and to catalog alltesting events, such as actions or reactions, or the lack of an actionsor reactions, taken by a test taker sitting for a particular test at aparticular day and time, and at a specific location, and then todetermine whether the testing events warrant changes to testingsecurity. The invention can include a computerized test administrationsystem that functions with a test security risk analysis managementsystem in order to allocate security resources intelligently. Variousembodiments of the invention are described in detail below.

In an embodiment, the system collects and uses available information toassess risk, prior or ongoing, associated with a test event. The datacollection and real-time use of that information for continuousassessment of risk for a test event has never been performed during testadministration. Prior art systems collect very little information abouta test event before, or even while the test is in progress, and do notuse that information to make security decisions (e.g., whether or not tohalt the test because of a detected security breach; whether to changethe levels of monitoring; etc.).

The invention provides for identifying risk levels for a test event sothat security resources can be applied intelligently and dynamically.Human resources are best applied to high-risk events. For example, thedetection of a test taker's use of a two-way radio (i.e., a high-riskevent) should be allocated greater security resources than a low-risk orno-risk circumstance, such as the test taker stretching or shifting intheir seat. Indeed, low-risk events may only be allocated automatedsecurity monitoring resources. This dynamic resource allocation is animprovement over current resource management methods, which currentlyresults in using the same resources regardless of whether the securityrisk is low or high. This type of dynamic resource allocation providedby the invention has not been performed and can significantly reduce theexpense of using humans as proctors. In some cases, the costs may bereduced by an estimate of 80% to 90%, due to the reliance on automatedmonitoring resources for low-risk test events, which generally comprisethe majority of risk events. The drastically lower costs of such testadministration encourages testing in these areas where the typical feesfor testing are significantly high for the market. This embodiment ofthe invention provides security for high-risk events, more accessibilityto testing, and value to areas of the world where testing has beeneconomically hindered.

With dynamic resource allocation provided by this invention, a testadministrator can provide an exam with premium security to a test takerat any location and at any time. This flexibility to take exams anywhereand anytime provides significant benefits for test administrators andtest takers. For example, testing can occur in places convenient to testtakers, such as homes, community centers, and workplaces. Furthermore,an individual with disabilities that restrict his/her travel could taketests in his/her home where he/she may use his/her own assistivedevices.

A detailed discussion of the methods and systems of the invention isprovided below. First, a system overview is discussed. Next, astep-by-step approach to dynamic resource allocation of test security isoutlined. Third, the system components are identified. A description ofa cloud computing system follows. The collection and retention ofrelevant data is outlined. Finally, incorporation of additionalparameters to the system is then delineated.

System Overview

The system is provided for creating and administering a secure,dynamically-monitored test to measure an individual's knowledge orskills, the system comprises:

-   -   a software application operating on a mobile computer device or        on a computer device, which is synced with at least one sensor        for monitoring the individual test taker, the software        application is configured to receive information related to the        individual test taker from historical databases of the system        and at least one sensor and to communicate the information        through a wired and/or wireless communication network to a risk        analysis management server located at a location remote from the        test location, and    -   a processor that is in communication through the wired and/or        wireless communication network with the software application, as        well as the risk analysis management server, the processor is        configured to call up from a database of the system upon        communication of the information to the risk analysis management        server: (1) a plurality of historical individual risk factors,        which may indicate a possibility of test fraud by the individual        test taker and have been previously uploaded to the system from        a public sources or made available by an owner or author of the        test or an employee, contractor, or agent of the owner or        author, (2) a non-individual risk factor, such as a location        risk factor, or other risk factors not tied to the individual        test taker, which has/have been previously uploaded by an owner        or author of the test or an employee, contractor, or agent of        the owner or author, and (3) threshold risk levels which have        been previously determined and uploaded by an owner or author of        the test or an employee, contractor, or agent of the owner or        author;    -   whereby the processor is configured to actively monitor the        information related to the individual test taker and the test        event;    -   whereby the processor is configured to determine an individual        risk profile by adding the information received from the        sensor(s) to the test event and individual risk factors to        create a modifiable risk profile for the test event;    -   whereby the processor is configured to determine a security        profile for the test taker by combining the individual risk        profile and other test event risk factors, including the        location risk factor and then to create a security profile to        compare to the threshold risk levels; and    -   whereby, when the processor determines that the security profile        is different from the initial threshold risk level, within a        range of tolerance, the processor is configured to notify the        software application.

FIG. 1 illustrates the system that includes a server comprising aprocessor aided by memory that communicates with sensor(s) anddatabase(s). The database(s) contains: (1) a plurality of historical andcurrent individual risk factors, which indicate a possibility of testfraud by the individual test taker and have been previously determinedand uploaded to the database by an owner or author of the test or anemployee, contractor, or agent of the owner or author, (2) a test eventrisk factor, including a location risk factor, which has been previouslyuploaded to the database by an owner or author of the test or anemployee, contractor, or agent of the owner or author, and (3) thresholdrisk levels which have been previously uploaded to the database by anowner or author of the test or an employee, contractor, or agent of theowner or author.

Creation of Individual Risk Profile

The system receives information related to prior or current testingevent(s) from the sensors and communicates such information to theprocessor when a test taker accesses the system. The sensors cantransmit the information at set intervals, when triggers happen, orcontinuously to the processor related to testing events. The testingevent may allow for the sensing of a number of forms such as actionsand/or inactions by the test taker, or simply gathering informationstored in databases from previous test events. For example, thesensor(s) for a current test event can measure the movement or lack ofmovement of the eyes of the test taker, whether or not the test taker'sbreathing or heart rate increases or decreases, or the speed at whichthe test taker reviews the question or submits an answer. In otherembodiments, the sensors can detect involuntary reactions such asbiological responses in a current test event. For example, sensors canbe used to take a test taker's heart rate, breathing rate, temperature,or level of perspiration. The system can also be used to detect moregross behaviors such as leaving the room where the test is taking place,and returning some time later, both of which could be considered to bean infraction of test taking rules.

The processor can then determine if the information collected by one ormore sensor(s) is a match to an individual risk factor within a range oftolerance. In certain embodiments, the individual risk factors can beset at levels that, once exceeded, indicate a likelihood of cheating orother types of test fraud. For example, a test taker's eyes focusing onanother test taker's test for more than a tenth (0.1) of a second canindicate a possibility of copying/cheating by the individual test taker.Conversely, the individual risk factors can be the change in certainreadings within a certain defined timeframe whose occurrence indicates alikelihood of cheating. For example, an increase of the test taker'sheart rate by 20 beats per minute within a thirty second period canindicate a possibility of cheating. In another example, the speed orpattern of answering questions can also indicate cheating withpre-knowledge or harvesting questions.

In the event the processor correlates data within a range of toleranceobtained from sensor(s) with individual risk factors, the system isnotified and/or the correlation noted in the individual risk profile. Inone embodiment, such relationship can be assigned a numeric value thatcan be added together to create a dynamic individual risk profile of thetest taker or the test event.

The system calculates individual risk profiles based on time passing,correlation with test fraud, data forensics analyses, hardiness ofpreventative test protections, history of the test taker,trustworthiness of the test site, and many more pertinent data points.The system can use algebraic models to combine these factors and theirdifferential weighting in order to calculate a current individual riskprofile. The system can dynamically determine the risk profile as thesevarious risk factors are continuously monitored and evaluated andchanges identified.

Incorporation of Non-Individual Risk Factors

The system can be configured to assess other factors not tied to theindividual taking the test, while creating a holistic security profilefor a test taker. For example, location risk factors can be used. In oneembodiment, the location in which the test is administered and/or thetiming of the administration can be taken into consideration or used toassign different weights to individual risk factors. By way of example,a test such as the MCAT can be administered in the United States andAustralia. Because those locations are on opposite ends of the planet,the individual tests may be administered at different times. With thespeed of the Internet, individuals who take the test earlier may be ableto steal questions and sell them to those individuals who are taking thetest later, thereby compromising test security. In order to combatsecurity breaches in this example, the individual risk factors can beassigned different weights depending on the location where the tests areadministered. For example, the system can be configured to place greaterweight on individual risk factors related to question theft (e.g.,taking unnecessary notes, identification of a photographic lens, etc.)in the location hosting the earlier test. For the location hosting thelater test, question theft may not be as great a concern, thereforegreater weight can be assigned to individual risk factors related tohaving prior question knowledge (e.g., not reading the entire questionbefore submitting the answer).

The system can be configured to provide a static value for the locationrisk factor. For example, more cheating may have previously beenobserved in the United States than in Australia. Consequently, testtakers in the United States can immediately be assigned a higherindividual risk profile than the test takers in Australia. Conversely,the location risk factor can be used as a multiplier for identifiedindividual risk factors. Again, if more cheating was observed in theUnited States than Australia, the United States can be assigned alocation risk factor multiple of 2 with Australia assigned a locationrisk factor multiple of 1. As a result, while wandering eyes can beinitially credited as 2 on the individual risk profile, regardless oflocation, the multiplier in the United States will result in theinfraction being recorded as a 4 on the test taker's individual holisticsecurity profile (i.e., 2 for individual risk profile multiplied by 2from the location risk factor equals 4).

Creation of a Security Profile

The system can be configured to create an individual risk profile frommany other risk factors, including the location risk factor to establisha holistic security profile for the individual test taker. The securityprofile is then compared to predetermined threshold risk levels todynamically allocate security resources.

Dynamic Security Resource Assignment

The system can be configured to use the individual security profile tointelligently allocate test security resources as needed. Knowing risklevels for a test event allows the system to apply security resourcesintelligently and differentially in real time. As a result, high-riskevents can be allocated greater security resources. Those with low or norisk can only be allocated automated security resources, i.e., fewer andless expensive security resources, but just as effective for the risklevel.

Furthermore, as the security profile for each test taker is dynamicallyevaluated, re-evaluated and adjusted by the system, the system canassign security dynamically with adjustments to compensate for changinglevels of risk. For example, a test taker that is originally categorizedas low-risk based on his/her initial, pre-testing security profile canengage in a high-risk testing event (e.g., looking at a neighbor'sanswers for more than a designated period of time). In that case, thesystem notifies the software application of such an event, the riskanalysis management software re-evaluates the individual's securityprofile, and the system can automatically assign added securityresources to that test-taker. Likewise, if the test taker has notengaged in even a low-risk behavior for a period of time, the risk canbe re-assessed as lower, and security resources could be re-assignedelsewhere.

Step-by-Step Approach

This section describes a non-limiting, exemplary embodiment thatincludes the steps of the process of the invention.

Step 1. When a test event is scheduled, the system calls up all priortesting events that occurred at the testing location or at otherlocations. Furthermore, as individual test takers register for the test,the system calls up all prior testing events that each test taker waspart of. The system checks to see if external risks are current, e.g.,the test has been disclosed on the Internet or cheating has beendiscovered on that test with a cluster of other test takers. The systemthen provides an initial starting risk level for that test event. Thescheduling process can also include such information as test start timeand other test-related information and the payment of fees.

Step 2. The system analyzes all available data using a multivariatestatistical model and assigns a risk factor(s) based on prior testingevents which may have occurred at the testing location and initialindividual risk factors based on prior testing events which each testtaker may have been part of.

Step 3. Based on the non-individual risk factor and initial individualrisk factors, the system assigns security resources to the event. Theresources can include a stricter authentication step, a combination ofhuman monitoring in differing degrees, and additional advancedtechnology monitoring. For the highest risk level, maximum securityresources can be applied during the entire testing session. For lowerrisk levels, fewer security resources are applied. In some embodiments,resources will not be required for lower risk levels including no riskand human security. Sophisticated automated monitoring, because it isinexpensive, would remain as the default security level for the minimumrisk levels.

Step 4. The system maintains logs of data collected and decisions madeat all steps of the risk analysis and management process for laterreview, in an applicant file or a test file or a system file. Thecollected data can include, but not be limited to, records of thebehaviors of test takers such as responses and latencies answering testquestions, audio and video behavior, communications with thesystem/proctors, calculations of risk by the system, scores, appeals, orassignment of proctor and security resources. The logs can be used forresearch, to respond to a challenge against any decisions, or for thetuning of the adjustment process of future risk factors in the future.

Step 5. When the test concludes, the system can provide an evaluation ofthe security applied to each test score. This step may provide evidencethat the test score was produced without interference from securitythreats, that the test score can be trusted from at least that securityperspective. The system can then provide a link for the test taker orother user of the test score (university admissions officer, teacher,parent, employer, etc.) so that the score can be accessed andindependently used, if necessary.

System Components

A non-limiting embodiment of the system includes a general-purposecomputing device, including a processing unit (CPU or processor), and asystem bus that couples various system components including the systemmemory such as read only memory (ROM) and random access memory (RAM) tothe processor. The system can include a storage device connected to theprocessor by the system bus. The system can include interfaces connectedto the processor by the system bus. The system can include a cache ofhigh-speed memory connected directly with, in close proximity to, orintegrated as part of the processor. The system can copy data from thememory and/or a storage device to the cache for quick access by theprocessor. In this way, the cache provides a performance boost thatavoids processor delays while waiting for data. These and other modulesstored in the memory, storage device or cache can control or beconfigured to control the processor to perform various actions. Othersystem memory can be available for use as well. The memory can includemultiple different types of memory with different performancecharacteristics.

Computer Processor

The invention can operate on a computing device with more than oneprocessor or on a group or cluster of computing devices networkedtogether to provide greater processing capability. The processor caninclude any general purpose processor and a hardware module or softwaremodule, stored in an external or internal storage device, configured tocontrol the processor, as well as a special-purpose processor wheresoftware instructions are incorporated into the actual processor design.The processor can essentially be a completely self-contained computingsystem, containing multiple cores or processors, a bus, memorycontroller, cache, etc. A multi-core processor can be symmetric orasymmetric.

For clarity purposes, an illustrative embodiment of the system is shownas including individual functional blocks including certain functionalblocks labeled as a “processor”. The functions the blocks represent canbe provided through the use of either shared or dedicated hardware,including, but not limited to, hardware capable of executing softwareand hardware, such as a processor that is purpose-built to operate as anequivalent to software executing on a general purpose processor. Forexample, the functions of one or more processors can be provided by asingle shared processor or multiple processors. The use of the term“processor” should not be construed to refer exclusively to hardwarecapable of executing software. Illustrative embodiments may includemicroprocessor and/or digital signal processor (DSP) hardware, read-onlymemory (ROM) for storing software performing the operations discussedbelow, and random access memory (RAM) for storing results. Very largescale integration (VLSI) hardware embodiments, as well as custom VLSIcircuitry in combination with a general purpose DSP circuit, can also beprovided.

System Bus

The system bus can be any of several types of bus structures including amemory bus or memory controller, a peripheral bus, and a local bus usingany of a variety of bus architectures. A basic input/output (BIOS)stored in ROM or the like, can provide the basic routine that helps totransfer information between elements within the computing device, suchas during start-up.

Storage Device

The computing device can also include a storage device such as a harddisk drive, a magnetic disk drive, an optical disk drive, a solid statedrive, a tape drive or the like. Similar to the system memory, a storagedevice can be used to store data files, such as location information,menus, software, wired and wireless connection information (e.g.,information that enables the mobile device to establish a wired orwireless connection, such as a USB, Bluetooth or wireless networkconnection), and any other suitable data. Specifically, the storagedevice and/or the system memory can store code and/or data for carryingout the disclosed techniques among other data.

In one aspect, a hardware module that performs a particular functionincludes the software component stored in a non-transitorycomputer-readable medium in connection with the necessary hardwarecomponents, such as the processor, bus, display, and so forth, to carryout the function. The basic components are known to those of skill inthe art and appropriate variations are contemplated depending on thetype of device, such as whether the device is a small, handheldcomputing device, a desktop computer, or a computer server.

Although the preferred embodiment described herein employs cloudcomputing and cloud storage, other types of computer readable media thatcan store data and that are accessible by a computer, such as magneticcassettes, flash memory cards, digital versatile disks, cartridges,random access memories (RAMS), read only memory (ROM), a cable orwireless signal containing a bit stream and the like, can also be usedin the operating environment. Furthermore, non-transitorycomputer-readable storage media as used herein can include allcomputer-readable media, with the sole exception being a transitorypropagating signal per se.

Interface

To enable user interaction with the computing device, an input devicerepresents any number of input mechanisms, such as a microphone forspeech, a web camera for video, a touch-sensitive screen for gesture orgraphical input, keyboard, mouse, motion input, speech and so forth. Anoutput device can also be one or more of a number of output mechanisms,such as, a display screen, speaker, alarm, and so forth. In someinstances, multimodal systems enable a user to provide multiple types ofinput to communicate with the computing device. The communicationsinterface generally governs and manages the user input and systemoutput. Furthermore, one interface, such as a touch screen, can act asan input, output and/or communication interface.

There is no restriction on operating on any particular hardwarearrangement. Here, the basic features can be easily substituted forimproved hardware or firmware arrangements as they are developed.

Sensors

The system includes at least one sensor for monitoring the test taker.The sensor can take many forms. For example, the sensor can be anauditory sensor (e.g., microphone), a video sensor (e.g., camera), abiometric sensor (e.g., pulse detector, keyboard patterns, voiceprint,facial recognition), a motion detector, a proximity sensor, or acombination thereof (e.g., a camera which is configured to also measurethe temperature of the test taker). In one non-limiting embodiment, theproximity sensor can be configured to monitor and confirm that the testtaker remains in a dictated location or within a range of the testinglocation. In another embodiment, the sensor can be a motion sensorconfigured to monitor the test taker's eyes. The sensor can also monitorless obvious behaviors, such as response patterns answering questionsthat reveal the use of pre-knowledge, for example.

In one non-limiting embodiment, the sensor can be mounted on a wearabledevice, such as a headset or glasses. The wearable device can, again,include biometric sensors, such as a pulse detection sensor, eyedirection sensors, a three-axis accelerometer, a GPS module, an RFsensor, an RFID or NFC chip, a galvanic skin response sensor, or othersensor to detect stress or continued presence or proximity to thetesting location. Such a wearable sensor can be configured to alarm orvibrate if the sensor is moved out of a proximity to the testinglocation, within a range of tolerance. The wearable sensor can alsorecord the field of view which is seen by the eyes of the test taker.Such a configuration can capture information about any visual aidsviewed or utilized by the test taker. In order to assure that the sensoris properly worn, a second visual sensor, such as a camera can be usedto monitor the test taker for the presence and proper use of the sensor.

In one embodiment, the sensor includes electronic components for wiredor wireless communication with the system. As a result, the sensor canavoid interference with the administration of the test. In oneembodiment, the sensor is replaceable or added to, such that differentsensors can be removed, which can allow the sensor to be cleaned.

In another embodiment, the sensor can include embedded monitoringcomponents that are configured to verify the identity of the user andmonitor the remote session environment for a duration of an entiresession. For example, the sensor can employ facial recognition softwareor finger print analysis to confirm the identity of the test taker atset intervals or continuously.

In another embodiment, a sensor detects the security design features ofthe test. A test that prevents the theft of the questions or differentmethods of cheating would provide critical information for theassessment of risk by the risk analysis and management system.

The system can include more than one sensor. Indeed, the system caninclude 2, 3, 4, 5, 6, 7, 8, 9, or 10 sensors, each of a different typeand different purpose. For example, the system may include two cameras,a microphone, a biometric sensor and a statistical response patternsensor. In one embodiment, the sensors cannot be easily tampered with.

Software Operations

The logical operations of the various embodiments disclosed areimplemented as: (1) a sequence of computer implemented steps,operations, or procedures running on a programmable circuit within ageneral use computer, (2) a sequence of computer implemented steps,operations, or procedures running on a specific-use programmablecircuit; and/or (3) interconnected machine modules or program engineswithin the programmable circuits. The system can practice all or part ofthe recited methods, can be a part of the recited systems, and/or canoperate according to instructions in the recited non-transitorycomputer-readable storage media. Such logical operations can beimplemented as modules configured to control the processor to performparticular functions according to the programming of the module. Forexample, if a storage device contains modules configured to control theprocessor. These modules can be loaded into RAM or memory at runtime orcan be stored as would be known in the art in other computer-readablememory locations. Having disclosed some components of a computingsystem, the disclosure now turns to a description of cloud computing,which is the preferred environment of the invention.

Cloud System

Cloud computing is a type of Internet-based computing in which a varietyof resources are hosted and/or controlled by an entity and madeavailable by the entity to authorized users via the Internet. A cloudcomputing system can be configured, wherein a variety of electronicdevices can communicate via a network for purposes of exchanging contentand other data. The system can be configured for use on a wide varietyof network configurations that facilitate the intercommunication ofelectronic devices. For example, each of the components of a cloudcomputing system can be implemented in a localized or distributedfashion in a network.

Cloud Resources

The cloud computing system can be configured to include cloud computingresources (i.e., “the cloud”). The cloud resources can include a varietyof hardware and/or software resources, such as cloud servers, clouddatabases, cloud storage, cloud networks, cloud applications, cloudplatforms, and/or any other cloud-based resources. In some cases, thecloud resources are distributed. For example, cloud storage can includemultiple storage devices. In some cases, cloud resources can bedistributed across multiple cloud computing systems and/or individualnetwork enabled computing devices. For example, cloud computingresources can communicate with a server, a database, and/or any othernetwork enabled computing device to provide the cloud resources.

In some cases, the cloud resources can be redundant. For example, ifcloud computing resources are configured to provide data backupservices, multiple copies of the data can be stored such that the datais still available to the user even if a storage resource is offline,busy, or otherwise unavailable to process a request. In another example,if a cloud computing resource is configured to provide software, thesoftware can be available from different cloud servers so that thesoftware can be served from any of the different cloud servers.Algorithms can be applied such that the closest server or the serverwith the lowest current load is selected to process a given request.

User Terminal

A user interacts with cloud computing resources through user terminalsor testing devices connected to a network by direct and/or indirectcommunication. Cloud computing resources can support connections from avariety of different electronic devices, such as servers, desktopcomputers, mobile computers, handheld communications devices (e.g.,mobile phones, smart phones, tablets), set top boxes, network-enabledhard drives, and/or any other network-enabled computing devices.Furthermore, cloud computing resources can concurrently acceptconnections from and interact with multiple electronic devices.Interaction with the multiple electronic devices can be prioritized oroccur simultaneously.

Cloud computing resources can provide cloud resources through a varietyof deployment models, such as public, private, community, hybrid, and/orany other cloud deployment models. In some cases, cloud computingresources can support multiple deployment models. For example, cloudcomputing resources can provide one set of resources through a publicdeployment model and another set of resources through a privatedeployment model.

In some configurations, a user terminal can access cloud computingresources from any location where an Internet connection is available.However, in other cases, cloud computing resources can be configured torestrict access to certain resources such that a resource can only beaccessed from certain locations. For example, if a cloud computingresource is configured to provide a resource using a private deploymentmodel, then a cloud computing resource can restrict access to theresource, such as by requiring that a user terminal access the resourcefrom behind a firewall.

Service Models

Cloud computing resources can provide cloud resources to user terminalsthrough a variety of service models, such as Software as a Service(SaaS), Platforms as a service (PaaS), Infrastructure as a Service(IaaS), and/or any other cloud service models. In some cases, cloudcomputing resources can provide multiple service models to a userterminal. For example, cloud computing resources can provide both SaaSand IaaS to a user terminal. In some cases, cloud computing resourcescan provide different service models to different user terminals. Forexample, cloud computing resources can provide SaaS to one user terminaland PaaS to another user terminal.

User Interaction

In some cases, cloud computing resources can maintain an accountdatabase. The account database can store profile information forregistered users. The profile information can include resource accessrights, such as software the user is permitted to use, maximum storagespace, etc. The profile information can also include usage information,such as computing resources consumed, data storage location, securitysettings, personal configuration settings, etc. In some cases, theaccount database can reside on a database or server remote to cloudcomputing resources such as servers or database.

Cloud computing resources can provide a variety of functionality thatrequires user interaction. Accordingly, a user interface (UI) can beprovided for communicating with cloud computing resources and/orperforming tasks associated with the cloud resources. The UI can beaccessed via an end user terminal in communication with cloud computingresources. The UI can be configured to operate in a variety of clientmodes, including a fat client mode, a thin client mode, or a hybridclient mode, depending on the storage and processing capabilities ofcloud computing resources and/or the user terminal. Therefore, a UI canbe implemented as a standalone application operating at the userterminal in some embodiments. In other embodiments, a web browser-basedportal can be used to provide the UI. Any other configuration to accesscloud computing resources can also be used in the various embodiments.

Collection of Data

In some configurations, during the testing described above, a storagedevice or resource can be used to store relevant data transmitted fromthe sensor(s) or the test taker's device to a database over a wired orwireless communication network. For example, how long it takes to readand process the question or the number of identified incidents ofcheating may be captured. Such data may be used to dynamically adjustrisk factors or the calculations based on those risk factors.

The data stored can also be incorporated into the disclosed system andmethods to refine the testing experience or evaluate security. Forexample, if a location experiences an increase in cheating incidents inthe first part of the test, the location risk factor can be increasedduring the test which can result in the allocation of additionalsecurity resources with relation to all the test takers at that site. Asa result, the information collected can serve more than one purpose(quality of measurement, better security, more fairness, and others).Those purposes can also be routinely evaluated.

Incorporation of Additional Parameters

Identity Verification

In a non-limiting embodiment, the sensors can be used to authenticatethe test taker before the administration of the test. In one example,the system can be linked to a public or private database that includesphoto or biometric information of the test taker (e.g., finger prints).Before the test can be presented to the test taker, the system can berequired to authenticate the right of the test taker to take the test.Such verification and confirmation can be accomplished in many ways, forexample, the use of facial recognition, keystroke pattern analysis,voice recognition software or fingerprint scanners, or many others,which can be hardware or non-hardware dependent.

Corrective Actions

In a non-limiting embodiment, when the security profile exceeds athreshold risk level, the entire system can be alerted. The system canthen allow a proctor monitoring the system and assigned to the testevent to: (1) review the security profile and/or the testing eventsidentified in the security profile; and/or (2) pause the test to discussthe issues with the test taker, and (3) other reasonable actions giventhe circumstances. Such review and/or communication can occur in personor remotely (i.e., the proctor remoting into the device on which thetest being administered or calling the person on a phone). To the extenta security breach is identified, the proctor can seize control of thetesting session. For example, if a threat is detected, the proctor canpause the test and deal with the test taker via a live or remote chatsession. When a test is paused, the current test item can be “covered”and the test timing can be suspended. If the problem is resolved to thesatisfaction of the proctor, he or she can “un-pause” the test allowingit to continue as if nothing had happened. If the problem cannot beresolved, the proctor has the options of (1) suspending the test, whichallows it to continue at another scheduled time, or (2) cancelling thetest event altogether. Such control provides a very effective tool inthe hands of the proctor to motivate compliance or to address the riskdirectly, one that is missing in the offerings of many online and someon-site proctoring service vendors today.

Example

FIG. 3 shows an exemplary embodiment of the disclosed system. At leastone database 310 feeds information to a processors 320, which may alsobe referred to as a Risk Analysis Management System (RAMS). Theinformation may be fed at set intervals or continuously.

In certain embodiments there are two or more databases 310. Suchdatabases can be segregated based on the type of information stored. Forexample, one database can hold information uploaded before a testingevent, such as: (1) prior incidents at the testing center, (2) testdesigns (e.g., multiple choice tests versus short answer or essaytests), (3) location of the testing event, (4) web monitoring reports(e.g., review of social media chatter prior to the test to see ifpotential cheating is being discussed), (5) data forensic reports, (6)system security, (7) examinee history, and (8) ability to authenticateexaminee. Conversely, another database may include information obtainedduring the testing event, such as: (1) test taker movement, (2) audio ofthe test taking environment, (3) real-time biometrics of the test taker,(4) proctor location, actions, and the test takers response thereto, (5)unauthorized communications by the test taker, and (6) the test taker'sadherence to the rules of the testing environment. The RAMS 320 takesthe information from the database(s) 310, combines the information andstatistically determines the level of risk associated with a test event.The risk is then assigned a classification 330.

In one embodiment, the classifications 330 are broken down as: (1) NoRisk, (2) Low Risk, (3) Medium Risk, (4) Medium High Risk and (5) HighRisk. Increased security measures are assigned to higher risk events.The classifications 330 are not static. Indeed, additional informationmay change the risk level dynamically. For example, an incidentoccurring in real-time during testing may elevate a risk level from LowRisk to High Risk almost instantaneously.

While this subject matter has been disclosed with reference to specificembodiments, it is apparent that other embodiments and variations can bedevised by others skilled in the art without departing from the truespirit and scope of the subject matter described herein. The appendedclaims include all such embodiments and equivalent variations.

What is claimed is:
 1. A system for monitoring an individual test takerand verifying compliance with rules of behavior with regard to a testevent, during a test session administered to an individual at a testlocation, the system comprising: a software application operating on amobile computer device or on a computer device, which are incommunication with at least one sensor for monitoring the test event,the software application configured to receive information related tothe individual test taker from the sensor and to communicate theinformation through a wired and/or wireless communication network to arisk analysis management server located at the test location or at alocation remote from the test location, and a processor that is incommunication through the wired and/or wireless communication networkwith the software application, as well as the risk analysis managementserver, the processor is configured to call up from a database of thesystem upon communication of the information to the risk analysismanagement server: (1) a plurality of predetermined individual riskfactors, which indicate a possibility of test fraud, cheating, or testtheft, by the individual test taker or others at the location, and havebeen previously uploaded by an owner or author of the test or anemployee, contractor, or agent of the owner or author, (2) anon-individual risk factor, which has been previously uploaded by anowner or author of the test or an employee, contractor, or agent of theowner or author, and (3) a set of threshold risk levels which have beenpreviously uploaded by an owner or author of the test or an employee,contractor, or agent of the owner or author; whereby the processor isconfigured to actively monitor the information related to the testevent; whereby the processor is configured to determine an individualrisk profile by comparing the information received from the sensor(s)against the individual risk factors to identify whether the risk profileneeds to be adjusted; whereby the processor is configured to determine asecurity profile for the test taker by combining the individual riskprofile and the non-individual risk factor into the test event risksecurity profile, and compare that security profile to the thresholdrisk level; and whereby when the processor determines that the securityprofile is above or below specific threshold risk levels, within a rangeof tolerance, the processor is configured to notify the softwareapplication.
 2. The system of claim 1 wherein, the software applicationallocates greater security resources if the security profile is abovemore of the threshold risk levels, and the software applicationallocates less security resources if the security profile is below lessof the threshold risk levels.
 3. The system of claim 1 wherein, based onactive monitoring of the test event by the sensor, the system isconfigured to dynamically increase or decrease the allocation ofsecurity resources based on how many threshold risk levels the securityprofile is above.
 4. The system of claim 3 wherein, based on activemonitoring of the test event by the sensor, the system is configured toincrease the allocation of security resources when the security profiletraverses the threshold risk level, within a range of tolerance, frombelow an individual threshold risk level to above the individualthreshold risk level.
 5. The system of claim 3 wherein, based on activemonitoring of the test event by the sensor, the system is configured todecrease the allocation of security resources when the security profiletraverses the threshold risk level, within a range of tolerance, fromabove an individual threshold risk level to below the individualthreshold risk level.
 6. The system of claim 1 wherein, thenon-individual risk factor is a location risk factor.
 7. A system formonitoring an individual test taker and verifying compliance with rulesof behavior with regard to a test event administered at a test location,the system comprising: a software application operating on a websiteaccessible through a wired or wireless communications network by aunique mobile computer device or a unique computer device which aresynced with at least one sensor for monitoring the test event, thesoftware application configured to receive information related to theindividual test taker and testing location from the sensor and tocommunicate the information through a wired and/or wirelesscommunication network to a risk analysis management server located atthe test location or at a location remote from the test location; and aprocessor that is in communication through the wired and/or wirelesscommunication network with the software application, as well as the riskanalysis management server, the processor is configured to call up froma database of the system upon communication of the information to therisk analysis management server: (1) a plurality of predeterminedindividual risk factors, which indicate a possibility of cheating orother types of fraud by the individual test taker and have beenpreviously uploaded by an owner or author of the test or an employee,contractor, or agent of the owner or author, (2) a plurality ofnon-individual risk factors, which have been previously uploaded by anowner or author of the test or an employee, contractor, or agent of theowner or author, and (3) a set of threshold risk levels which has beenpreviously uploaded by an owner or author of the test or an employee,contractor, or agent of the owner or author; whereby the processor isconfigured to actively monitor the information related to the testevent; whereby the processor is configured to determine an individualrisk profile by comparing the information received from the sensoragainst the individual risk factors to identify any that might requirethe risk factor to be adjusted; whereby the processor is configured todetermine a security profile for the test event by combining theindividual risk profile and the non-individual risk factors, and comparethe current security profile to the threshold risk level; and wherebywhen the processor determines that the security profile is above orbelow specific threshold risk levels, within a range of tolerance, theprocessor is configured to notify the software application.
 8. Thesystem of claim 7 wherein, the software application allocates greatersecurity resources if the security risk profile is above more thresholdrisk levels, and the software application allocates less securityresources if the security risk profile is below less threshold risklevels.
 9. The system of claim 7 wherein, based on active monitoring ofthe test event by the sensor, the system is configured to dynamicallyincrease or decrease the allocation of security resources based onwhether the security profile is above or below the threshold risk level.10. The system of claim 8 wherein, based on active monitoring of thetest event by the sensor, the system is configured to increase theallocation of security resources when the security profile traverses thethreshold risk level, within a range of tolerance, from below thethreshold risk level to above the threshold risk level.
 11. The systemof claim 9 wherein, based on active monitoring of the test event by thesensor, the system is configured to decrease the allocation of securityresources when the security profile traverses the threshold risk level,within a range of tolerance, from above the threshold risk level tobelow the threshold risk level.
 12. The system of claim 7 wherein, thenon-individual risk factor is a location risk factor.
 13. A method formonitoring an individual test taker and verifying compliance with rulesof behavior with regard to a test event, the method comprising:receiving information related to the individual test taker from a sensorfor monitoring the individual test taker and test taking environmentsynced through a wired and/or wireless communication network with asoftware application operating on a mobile computer device or on acomputer device; upon receiving the information, using a processor toverify the identity of the individual test taker and call up: (1) aplurality of predetermined individual risk factors, which indicate apossibility of cheating or test theft by the individual test taker, (2)non-individual risk factors, and (3) a set of threshold risk levels;creating an individual risk profile by comparing the informationreceived from the sensor against the individual and non-individual riskfactors; combining the individual risk profile with the non-individualrisk factors, creating a security profile for the test event; comparingthe security risk profile of the test event to the threshold risklevels; and notifying the software application if the security riskprofile is above or below a specified threshold risk level.
 14. Themethod of claim 13, further comprising: assigning security resourcesbased on whether the security profile is above or below the specifiedthreshold risk level.
 15. The method of claim 13 further comprising:dynamically increasing or decreasing the allocation of securityresources based on active monitoring of the test event by the sensor.16. The method of claim 15, wherein, increased security resources areallocated if the security profile crosses the specified threshold risklevel, within a range of tolerance, from below the specified thresholdrisk level to above the specified threshold risk level.
 17. The methodof claim 15, wherein, decreased security resources are allocated if thesecurity profile crosses the specified threshold risk level, within arange of tolerance, from above the specified threshold risk level tobelow the specified threshold risk level.
 18. The method of claim 13,wherein, the non-individual risk factor is a location risk factor.